Transactional logging involves maintaining a transactional log that durably records a time serial history of transactions in a system. The transactional log provides information for restoring a system to a particular state in time prior to a system failure. A transactional logging system must be able to reliably and accurately restore logging functionalities after such a system failure. In some transactional logging systems, log files are arranged as either real (i.e., dedicated logs) or virtual (i.e., multiplexed) logs that are presented as opaque file handles or file objects that are exposed to user- and kernel-mode clients.
It would be desirable to be able to preserve log file semantics, including security semantics, between real and dedicated log files. An objective is that log client application logic should be agnostic as to whether its underlying log is running in a dedicated or multiplexed mode. That is, implementing an application with either a dedicated log client or multiplexed log client should have no impact on the application logic. A particular virtual log would therefore need to be secured against access by a user of any other virtual log stream, unless such a user is granted explicit access, because all virtual log streams share the same physical multiplexed log. Such security is desirable in order to prevent a pathological log client with a malicious intent from inappropriately accessing another log stream or data from containers used in the file system which underlies the multiplexed log. Accidental or inadvertent access to another log client's virtual stream and/or data is also preventable with such security.
This Background is provided to introduce a brief context for the Summary and Detailed Description that follows. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to only those implementations that may solve any or all of the disadvantages or problems presented above.